Stop reporting expected student validation errors to Sentry#938
Conversation
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
This PR updates the SchoolStudent::Create concept to treat Profile API “student validation” failures as expected outcomes rather than unexpected exceptions, reducing Sentry noise when user-facing validation fails during student creation.
Changes:
- Add a dedicated rescue for
ProfileApiClient::Student422Errorto avoid reporting expected validation failures to Sentry. - Adjust unit specs to assert the returned error is the translatable
errorCodeand that Sentry is not invoked for this case.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| spec/concepts/school_student/create_spec.rb | Updates expectations for Profile API validation failures (returns errorCode, does not call Sentry). |
| lib/concepts/school_student/create.rb | Adds a specific rescue for Student422Error so expected validation errors aren’t sent to Sentry. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Test coverage92.17% line coverage reported by SimpleCov. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
lib/concepts/school_student/create.rb:13
- This rescue path relies on
e.to_sto return the translatable Profile validation code. That happens today becauseStudent422Errorsets its exception message fromerrorCode, but it’s an indirect coupling (and can degrade to the exception class name if the payload shape changes). Prefer extractingerrorCodedirectly frome.errorsand only fall back toto_swhen it’s missing.
rescue ProfileApiClient::Student422Error => e
OperationResponse[error: e.to_s]
rescue StandardError => e
Sentry.capture_exception(e)
OperationResponse[error: e.to_s]
| rescue StandardError => e | ||
| Sentry.capture_exception(e) | ||
| response[:error] = e.to_s | ||
| response | ||
| OperationResponse[error: e.to_s] |
There was a problem hiding this comment.
Doesn't need to be changed as part of this, but I'm unsure if there is value in having this here since there's already something in the api controller that converts errors to an API response. I think this would only be useful if there there is a need in this controller that this is used to render errors in a different format to what the base api controller does.
There was a problem hiding this comment.
That makes sense. We can create a separate ticket to discuss the exact cleanup later.
Related to Sentry issue https://github.com/RaspberryPiFoundation/digital-editor-issues/issues/1583
Points for consideration:
What's changed?
Profile API returns an isComplex validation error.
Steps to perform after deploying to production
No additional steps are required. There are no migrations, configuration changes, or data backfills.